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The undersigned, KURT BROOKS UHLIR, CHRISTOPHER DOUGHERTY, 
MICHAEL V. SHUMAN, and ROY CASINO, hereby declare that: 

1. We are co-inventors of the invention described and claimed in the above-identified 
patent application. 

2. Before January 21, 2003, we invented a new method for deriving products from a 
source geographic database. Part of this new method included using or extracting data from a 
source geographic database to provide a dataset used in developing video games that depicted 
real geographic locales as part of play scenarios. An application programming interface used for 
developing the video games from the specific dataset was also provided. The source geographic 
database included navigation attributes including data representing road segments, and the source 
geographic database was also used to provide a dataset to develop real-world navigation systems. 

3. Before January 21, 2003, we prepared invention disclosure statements describing our 
inventive ideas. We provided the invention disclosure statements to the Legal Department of the 
assignee of the subject patent application, A copy of an invention disclosure statement prepared 
by us prior to January 21, 2003 folly disclosing the claimed invention is attached hereto (Exhibit 



4. All statements made herein of my own knowledge are true and that all statements 
made on information and belief are believed to be true, and further these statements are made 
with the knowledge that willful false statements and the like so made are punishable by fine or 
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imprisonment, or both, under Section 1001 of Title 18 of the United States Code, and that such 
willful statements may jeopardize the validity of the application or any patent issuing thereon. 



HjRT BROOKS UHLIR 




iPHER DOUGHERTY 



MICHAEL V. SHUMAN 



ROY CASINO 



Date 




-44 




Date 






Date 







Date 



NAVTEQ North America, LLC 
425 West Randolph Street 
Chicago, IL 60606 
(312) 780-3054 
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NAVIGATION TECHNOLOGIES CORPORATION 
INVENTION DISCLOSURE STATEMENT FORM 



(Return electronic copy and 
folly executed hard copy to Legal Department) 




(to be filled out by Legal TXipt.) 



Shorthand Name for Invention: Ideas for a "Game API" f or Use in Cr&axing Games 



Developers Who Contributed to Invention: 1. Rov Casino 



3. Chris Dougherty 

5. 

7. 



2. Mike Shuman 

4. TCnrt IThlir 

6. 

5. 



Par* (or Month) on Which Development Began: m ^■^^E 

If Known, First Date (if any) on Which Development was: 

(a) described in a CONFIDENTIAL document released outside of NTC . 

(b) described in a CONFIDENTIAL conversation with a non-NTC employee m 

(c) described in a NON-confidentia) document released outside of NTC 

(d) described in a N ON -confidential conversation with a non-NTC employee 

(e) included in any version of a product released outside of NTC 

(f) used internally at NTC in the normal course of operations: 

(g) discussed at a Brainstorming Session for IDS No, j , M 

Summary of Invention: 

NTC currently offers SDAL and NavTools for use m creating in-vehicle navigation applications. Furthermore, NTC offers 
RTM for use in creating real-time on-bbard or off-board applications. The idea proposed in this IDS is for an API that wilJ 
offer interfaces for creating navigation based gaming applications. The general idea of NTC offering a game API as well as 
some specific ideas are proposed in this IDS. The ideas and related concepts for the games are proposed in numerous other 
IDS forms. This IDS directs its focus on the new and unique ideas necessary for the gaming API (Other documents exist 
that detail the business reasons justifying NT's interest in being a part of the huge game market.) 

Key Words for Invention: __ . . 

Navigation, games, APL Ground, Truth, Gaming, Electronic Games, Video Games, LBS, LBG 

Advantages of Invention (to the extent known): „ 

Allows one to easily create applications using NAVTECH data 

Allows NAVTECH data to become more widely known based on name recognition through people playing games on PCs, 
phones, internet, etc. 

Opens, up a new business market for NAVTECH data simply by offering a new API 

API could be based heavily on SDAL and NavTools code maldng development more e ffective 

Detailed Description of Invention 

* describe function(s) performed 

* describe with particularity the way in which each function is achieved (e,g., if the invention 
is a process, describe each step of the process): 
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The Game API will offer functions broken into four key areas thai differ from current NTC APIs: 

« 

I. Functions io convert NAVTECH data to other formats suitable for games 

IL Functions for high-speed display necessary for games 

EEL Functions for aesthetically pleasing display formats necessary for games 

IV. Function to easily integrate NAVTECH data with other data content necessary for games 

Each of the four areas will be described in more detail below. 

I. Functions to convert NAVTECH data to other formats suitable for games 

Overview: 

These functions allow conversion of NAVTECH data to formats for use with 3-d display, cell phone display, 
PC gaming via internet display, and others. The idea here is that the NAVTECH database should remain 
focused on navigation applications- In turn, these functions will use the NAVTECH database, but offer data 
necessary for game play in one of the game formats. For example, a "cannonball run" type of racing game 
would require the NAVTECH data to appear in 3-d format as if a car were driving the roads. This would allow 
drivers to race across the United States (or other region), allow them to choose to drive on any road, allow the 
games to drive realistic routes with real knowledge of speed limits, signage, and more integrated into their 
game play. 

Example: 

3-d display: The 3-d display functions will allow games to "travel" along roads from a driver's perspective. 
For example, a driving game could allow one to race a route from Chicago to St. Louis. 

Functions: 

5_djlisplay( link ID, location, direction _pfjravel t Displaylnfo) 

link ID (input). . . the NAVTECH link ID of the desired link for display 

location (input). . .the actual location along the link (expressed in percentage along the link) 

direction_ofjravel (input). . .direction of travel (from reference node or to reference node) 

Displaylnfo (output). , .a structure (not defined here) that holds all information necessary for displaying a 3-d 

image of the road and related attributes. The image drawn on a display using this information would be a 

computer rendered view of what a driver would see from a car located on the road at this point 

Example: 

iniemet_display: The internet display functions will allow incremental updates of internet displays for game 
play. For example, a first display screen would show full detail of a certain geographic area in 2d or full 3d. 
Further updates to the screen will only send necessary information to indicate changes to the current display. 
This method of sending only changes will allow faster updates necessary for game play over the internet A 
function like this could allow a set of gamers across the nation connected only by internet connections to play 
competitive games based on NAVTECH data with each other in real-time. 

internet_display(region, 2d_3d Jlag, location, Displaylnfo) 

region (input). . .bounding box region to display 

2d__3d_flag (input). . .whether 2d or 3d display should be shown 

location (input).. . gamer's location on the requested map 

DispJaylnfo (output). . . a structure (not denned here) that holds all information necessary for displaying an 
image of the road and related attributes. Further updates to this display would only send changes to allow for 
fast transmission across internet connections and fast display updates. 

More: 
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Those are only rwo representative type fractious thai could exist in a gan^ API. Clearly, numerous additional 
functions will be necessary in the actual implementation. 

II. Functions for high-speed display necessary for games 



Overview: 

Current NavTools display tools are not optimized for high-speed updates or continuous movement The game 
API will require functions that support these rypes of scenarios. This will allow a driving game, for example, 
to give ihe appearance that a vehicle is being driven along a road way created using NAVTECH data. 



Requirements: 

No new functions will necessarily be required versus current NavTools functions as much as more optimization 
will be required. Concepts such as high speed polygon display and other video game derived display 
technologies will have to be incorporated into The game API tool set This integration of video game 
technology into a game API will allow the NAVTECH database to be drawn in 2d or 3d at very high speeds. 

IE. Functions for aesthetically pleasing display formats necessary for games 



Overview: 

Current NTC APIs disp3ay maos for navigation purposes. The game API will require changes so that displays 
can be oriented to more aesthetically pleasing display formats. Formats that include road widths and lane 
stripes will be incorporated into the display functions. Furthermore, attributes such as road names will be 
optional in the display as road names may not always be necessary for games. Moreover, games may choose to 
leave off the road names for the sake of speed. 



Requirements: 

The display formats for games will require that NAVTECH data (intended for navigation applications) will 
have additional visual information attached during the process of preparing for display. For example, a game 
may query for a display that includes stripes on the lanes and shoulders along the edges of the road. Further 
examples are the inclusion of road signs so that a game player sees a speed limit sign, for example, pass by as 
he/she drives. 



Function: 

se(__display _pa?~ameters( visual _aiiribuLeJist) 

visual_attribute list (input). . .this parameter allows one to set visual attributes such as whether lane stripes 
should be added to the roads for display, whether signs should be added to the display, whether shoulders or 
curbs should be added, and other attributes of this son intended to visually aid a driver playing a game and not 
necessarily aiding in navigation. 

IV. Function to easily integrate NAVTECH data with other data content necessary for games 



Overview: 

Many games will also desire to integrate information such as the look of other vehicles on the roads, traffic 
information on the roads, the look of buildings along the road, and other such examples. The game API will 
allow the game designers access to the polygonal display tools so that these additional features could easily t 
integrated with the NAVTECH data. For example, a game designer may want to populate the roads being 
driven with actual vehicles on the market. In that case, the game designer would obtain vehicle modeling 
information fiom other sources and feed it to the game API so that the vehicles could be placed on a 3-d 
NAVTECH road map display. 



Function: 
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integ}-ate^externa!jnj<sr mazion(po}ygonaljnfoi7nation, location) 

polygODalJnformation (input) ...ibe polygon modeling information necessary to render a particular geometrical 
shape such as a building or vehicle. 

location (input)., .the location to display the polygonal j^omiaoon. This would allow one to place buildings 
along the road or other vehicles along the road. 



Please place an "X 77 next to the appropriate statement: 
X No design documents exist 

The follotving design documents exist (and copies are attached): 



Signature: ; Daie 3 

( of prepare r-dcvclopcr) 

Type Name: Rov Casino 
Signature(s) of Contributing Developers: 

1. Name: „ ^ ate: - 

2. Name: ; D ate: - 

3. Name: „ Daie: . 

4. Name: . Daie:^ 

5. Name: Daie: , 

6- Name: m Daie: . 

7. Name: Date; . 
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